Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/fddi/fddi-minutes-90feb.txt

Text File | 1993-02-17 | 7KB | 152 lines

CURRENT_MEETING_REPORT_


Reported by Dave Katz/Merit

MINUTES

The group met on the afternoon of Wednesday, February 7.


  1. Document Overview:  Dave Katz gave an overview of the current draft
     IP Over FDDI document, which had been distributed to the
     [e-mail] mailing list, for the benefit of those new to the
     working group.  Highlighted were differences between the current
     draft and RFC 1103.
  2. Outstanding Technical Issues:
     (a) A and C Indicators:  A discussion ensued on the issue of the A
         (Address Recognized) and C (Frame Copied) indicators.  The
         current draft states that "the A and C indicators shall be
         ignored for IP and ARP packets." Objections were raised that
         this would appear to preclude ANY use of these indicators, such
         as the management of ARP cache entries.  The document editor
         gave his view that a standard can only specify
         externally-visible behavior, and that implementation decisions
         such as ARP cache management could not be precluded.
         The intent of the language regarding A and C was to preclude
         the use of link-level retransmission in the face of apparent
         transient congestion in the receiver.  The pros and cons of
         retransmission were debated.  After some discussion, the group
         decided that the usage of the A and C bits would be specified
         as an implementation decision, with an explicit note that link
         level retransmission may in fact occur.
     (b) Dual-MAC Issues:  Dave Katz provided an overview of the issues
         regarding the use of dual-MAC stations.  Two basic approaches
         are possible:
          o Separate IP subnetworks on each ring
          o A single IP subnetwork spanning both rings, with both MACs
            using the same IP address (for load splitting)
         With separate IP subnetworks, the major technical requirement
         seems to be that all stations properly support subnetting (only
         sending ARPs for stations on the proper subnet, for example) so
         that the ring may wrap and unwrap without stations on the two
         rings learning each others' MAC addresses.  A further issue is
         that if a dual-MAC station wraps the ring, the SMT
         Configuration Management state machine implies that one of the
         MACs may be disconnected for the duration of the wrap.
         When a single IP subnetwork is used, the current ARP protocol
         is insufficient to maintain knowledge of the binding between
         MACs and rings.  In particular, if the ring is wrapped and an
         ARP is sent for an IP address, two responses may be received at
         each source MAC, and it becomes ambiguous when the ring unwraps
         as to which ring each MAC is connected.  This problem is made
         more difficult in the face of the lack of a reliable

                                   1






         event-driven indication of the wrap state of the ring
         (especially if two MAC-less concentrators are performing the
         wrap).  Further complicating this problem are "translucent"
         bridges between Ethernets and FDDI rings.
         It was generally agreed that both the single-subnetwork and
         dual- subnetwork configurations are desirable, and that they
         should both be defined, and configurable on a per-LAN basis.
         Doug Hunt of Prime presented a straw-man proposal of how to
         deal with the single IP subnetwork case.  It suggests the use
         of an extension to the ARP protocol that allows the unambiguous
         determination of the ring on which a MAC is present, even in
         the face of the ring wrapping and unwrapping.  This proposal
         and other potential solutions were discussed by the group.
         It was recognized that the development of the single-subnetwork
         solution, which is generally viewed as being desirable, is
         going to take a significant amount of work.  No decision was
         made regarding the mechanism to be used.
  3. Document Progression and Future Work:  The question of the
     progression of one or more documents into the IETF standards track
     was discussed.  The choices of action balance a need to produce a
     standard very quickly versus producing a complete standard.
     The choices are:
     (a) Progress the current document immediately as a single-MAC
         standard and begin work on a separate dual-MAC standard.
     (b) Quickly write a dual-subnetwork, dual-MAC solution, add it to
         the current document, progress it as a standard, and begin work
         on a separate single-subnet, dual-MAC standard.
     (c) Add single- and dual-subnetwork, dual-MAC solutions to the
         current document and progress it as a standard.


Choice a) has the advantage of starting the base document through the
standards process most quickly, significantly moving up the date at
which a standard could be published and conformant products could be
produced by vendors.  It has the disadvantage of being only a partial
solution, and may give the impression of favoring single-MAC stations.

Choice b) includes support for dual-MAC stations, but delays the
progression of the base document and gives the impression that the
dual-subnetwork solution is the "right" solution for dual-MAC stations.

Choice c) provides the most even-handed document in terms of the various
solutions, but seriously delays the publication of any sort of standard.

The group decided to pursue the following course:

   o Make minor additions and corrections to the current draft,
     including a statement to the effect that a dual-MAC solution is to
     follow.  Forward this draft into the February X3T9.5 meeting.
     Incorporate any additional comments from X3T9.5 into the draft and
   o publish it immediately thereafter as an Internet Proposed Standard.
   o Create a new working group to address "multi-rail" LANs, of which
     FDDI is a specific case, with the intent of producing an Internet

                                   2






     Standard on the subject.  Hope was expressed that generalizing this
     problem would not significantly delay the development of a solution
     for FDDI.


ATTENDEES

    Doug Bagnall                  [e-mail]
    Samir K. Chatterjee           [e-mail]
    Noel Chiappa                  [e-mail]
    Dino Farinacci                [e-mail]
    Ken Hays                     [e-mail]
    Binh Hua                     no email
    Doug Hunt                     [e-mail]
    Ronald Jacoby                 [e-mail]
    B.V. Jagadeesh                [e-mail]
    Dave Katz                     [e-mail]
    Dave Piscitello               [e-mail]
    Michael Reilly                [e-mail]
    Steve Senum                   [e-mail]
    Steve Shibuyama               no email
    Mary Jane Strohl              [e-mail]
    Dean Throop                   [e-mail]



                                   3